by: Eric Carr
Click Here to see a
43.5KB bitmap image of artwork
which goes with this article, entitled:
Make it Your Policy to be Shady
Click Here to see a
21.7KB bitmap image of artwork
which goes with this article, entitled:
Switch to Manual
I KNOW YOU. You think User Profiles are great for keeping novice users out of trouble, and for preventing more experienced users from getting in and mucking things up. But you want a more fundamental level of control--say, at the system level.
You want System Policies. Think of System Policies as overrides to the local machine's Registry. Stored on the server, System Policies are downloaded into the local machine's Registry during log-in. They overwrite the local machine's settings, enforcing a consistent set of rules for every user who logs into the network. Whereas User Profiles can make changes to the desktop settings in the Registry, System Policy settings can alter the desktop's properties (USER.DAT) as well as the log-in and network-access properties stored in SYSTEM.DAT. In essence, System Policies define what properties the user can set.
You create System Policies with the System Policy Editor (SPE), a graphical tool that presents system settings in a tree format, much like the hardware components in Control Panel's system folder. The Editor uses a template file to display (and change, when necessary) the contents of the Registry. (Mastering template programming is complex enough to be a university-level course. See So You Wanna Be a Systems Programmer.)
The SPE provides some powerful facilities for controlling what you can accomplish on a Windows 95 desktop. But this power doesn't come cheap: You can inadvertently destroy the user's current configuration if you're not careful about what you change and what you leave alone. For example, if you suddenly decide to put a bitmap on users' desktops without warning, I guarantee you'll get feedback--and it won't all be positive.
Although some power is good to keep chaos in check, you've heard the saying about absolute power. It's probably not a good idea to destroy users' efforts to customize desktops unless you have considerable management backup.
The check boxes in the Policy Editor (in Policy File mode) operate a little differently than normal. If they're checked, the policy will be implemented; if they're empty, the policy won't be implemented. If they're shaded, the setting won't be changed from the current setting, and Windows 95 won't make any changes to the existing policy.
For instance, if you suddenly decide everyone should be using the Microsoft Client for NetWare to connect to your NetWare server, be sure to select the options to use the Client for NetWare, as shown in the left-hand screenshot in the 43.5KB bitmap image Make it Your Policy to be Shady. That would ensure that everyone was using the client. Later on during the session, when you realize not everyone is set up to use this method of network attachment, your first instinct may be to go back and clear the check marks, as shown in the center screenshot.
Don't do it. When you clear the check marks, you indicate that Client for NetWare shouldn't be used; therefore, all the users who already employ this method of attachment will have their configurations destroyed the next time they log in and download the policy into their Registries. Whoops!
The correct response is to click on the boxes until they become shaded, as shown in the right-hand screenshot. This indicates the policy remains unchanged from the current setting (the setting in force when you invoked the Policy Editor).
The moral of the story is: When you have to decide whether to implement or remove a policy, tread carefully and think about the ramifications of your actions.
You'll find many more goodies like the SPE on the CD version of Win95. If you're serious about getting and using all the features I discuss here, get the CD. You install the Policy Editor via Windows 95's Add/Remove Programs applet in the Control Panel. Run the applet, select the Windows Setup tab and click on the Have Disk button. In the dialog box, choose Browse and then enter the path to the \ADMIN\APPTOOLS\POLEDIT directory on the Win95 CD. Click on OK and then on OK again. In the Have Disk dialog box, check the System Policy Editor option. It wouldn't hurt to install the Group Policy capability at this point, so you may as well check that box, too. Group Policies are applied to Windows 95 users and machines included in one or more network groups--either NetWare or Windows NT. Later, you can install Group Policies using these same instructions.
Finally, click on the Install button. Microsoft recommends you restrict SPE installation to a small number of users. It's powerful and could be potentially damaging if used by a lot of people. Think carefully about who should have access to this application.
Fire up the Policy Editor to see what's going on by running the POLEDIT application. The editor operates on each part of the Registry--the user portion and the computer component--but not both simultaneously. I don't have the space here to detail all of these settings, so I encourage you to do some exploring. Start by selecting File/New. When the default user and computer icons appear, double-click on either to see the categories of policies.
You can use the Policy Editor in one of two ways. In Registry mode, the editor operates directly on the local computer's Registry. When you open the Registry, you'll note the editor initially shows only the local user and the local computer. (I'll deal with remotely connected computers in a future installment. If you can't wait, read Chapter 16 of the Microsoft Windows 95 Resource Kit to see how to set up and manage remote control and administration.) When you use the Policy Editor in Registry mode, just click on the portion of the Registry you want to set policy for--either the user or the computer. Changes you make become effective after you restart the machine. Use this mode with caution, because you could end up making changes that will affect your machine.
Use the SPE to create policy files you store on the server and download whenever a user or member of a group logs into the network. This mode is sometimes called Policy File mode. It doesn't directly affect the Registry--rather it creates the file containing directives that are downloaded into the Registry during the log-in process. I used the Policy File mode in my earlier example. It permits you to explore the capabilities without making changes to your Registry. Don't save the file while you're getting used to the Policy Editor. When you're ready, though, save it as CONFIG.POL.
Adding policies for specific groups is a snap. From the Edit menu, select Add Group. To get a pick list of the available groups, click on the Browse button and stand back. We did this on our server in San Mateo and got a huge list of users, groups and print queues.
You can define only those groups that have been previously defined within the network operating system. As you might expect, Group Policies look exactly like User Policies, because groups are made up of multiple users. To ensure Group Policies are enforced, install GROUPPOL.DLL on each participating computer in the group. Do this when you first deploy Windows 95 in a custom installation script. Or, you can go around to each computer and do it individually, just as you installed the SPE.
To activate the new policy that you've constructed, copy the CONFIG.POL file to the server. For Windows NT, place the file in the NETLOGON directory; NetWare users should place the file in the PUBLIC directory. Once again, you'll need to be running the 32-bit client to make this work automatically, but there are workarounds if you're running another type of client, as with User Profiles. To configure for manual downloading of System Policies, edit the local Registry of the machine using the SPE, as shown in the 21.7KB bitmap image Switch to Manual. Make sure you specify the complete path and filename for the manual download.
You need to install the SPE on every machine to make some of these changes. At the very least, you'll need a disk containing the SPE that you can carry around as you visit different desktops, or the editor loaded in a secure area of the network that only you can access. Although these approaches will all work, there's a more elegant method of managing and controlling remote computers' Registries--and that's what I'll show you next month.
Contributing Editor Eric Carr is owner of F1, a Mountain View, Calif.-based consultancy. Contact Eric in the "Networking Windows" topic of WINDOWS Magazine's areas on America Online and CompuServe. To find his E-Mail ID Click Here
Although the System Policies supplied with Win95 are comprehensive, they don't address the needs that could crop up when you're deploying a custom or in-house-developed application. For these requirements, you may need a customized version of the System Policy template. You can create one using a text editor. This is not for the faint of heart, but it can be done. The text below--from the \WINDOWS\INF\ADMIN.ADM file--shows what it takes to create two small policies. So, dust off your books on structured programming, bone up on object-oriented terminology and you, too, can become a systems programmer.
CATEGORY !!Logon
POLICY !!LogonBanner
KEYNAME
Software\Microsoft\Windows\CurrentVersion\Winlogon
PART !!LogonBanner_Caption EDITTEXT
VALUENAME "LegalNoticeCaption"
MAXLEN 255
DEFAULT !!LogonBanner_DefCaption
END PART
PART !!LogonBanner_Text EDITTEXT
VALUENAME "LegalNoticeText"
MAXLEN 255
DEFAULT !!LogonBanner_DefText
END PART
END POLICY
POLICY !!ValidatedLogon
KEYNAME Network\Logon
VALUENAME "MustBeValidated"
END POLICY
END CATEGORY
by: John D. Ruley
Click Here to see a
12.9KB bitmap image of artwork
which goes with this article, entitled:
Almost RISC-Free
I'VE POLISHED OFF my crystal ball just in time for the New Year, so I can bring you the first-ever State of NT report. I've drawn from Microsoft's public statements, Deep Dark's and other confidential sources' whisperings, and other industry information. It's guaranteed to be as accurate as possible--meaning somewhere between blind guesswork and gospel truth.
Let's start with 1996. First, we'll see public demos of the next NT product, Microsoft's Shell Update Release (SUR).
Microsoft has already shown it at Networld/Interop, and I'll bet that by now we've seen more of it at Fall Comdex. Aside from the Windows 95-style Explorer interface, we'll see other features in the SUR (see the The Big SUR).
Once Microsoft releases SUR, we'll see new NT/Back Office products from the company. Among these will be the Gibraltar Internet server, maybe Microsoft's Catapult Firewall, the much-anticipated Exchange messaging server and a new version of Systems Management Server (SMS) with secure remote control for NT clients. (Deep Dark tells me this may turn up in a Service Pack to SMS 1.1). These pieces will be integrated into the obligatory new version of Microsoft's Back Office bundle, which should appear around the third quarter. By that time, developers should see Cairo-related developmental betas: Network OLE, Object File System (OFS) and Distributed File System (DFS).
Here's where I go out on a limb. Look at the calendar, consider everything I've just mentioned and think about something Deep Dark once said ("If we can't ship a new release by Comdex, we can't ship it by the end of the year!"). I can't see Microsoft shipping even a beta version of Cairo this year. Developers will get an early peek, but even they won't get a full operating system beta until January 1997. It may take that long just to merge OFS and DFS into a single file system.
Slipping to 1997 means Cairo should have no trouble integrating all the anticipated major features: Plug-and-Play support (which will make possible a new spate of hot-swappable peripherals for network servers), Kerberos networkwide security and cluster support integrated directly into the NT kernel (jointly developed by Microsoft and Digital). By then, the Windows 95 team will have a new version of its OS with Network OLE support in place to act as a Cairo client. There should be another round of new server-side products by then, but I have no idea what they'll be.
It's interesting to look back at what seemed important last January. The Power
PC topped everyone's list. Even Microsoft called NT 3.51 the PowerPC version. What impact has the PowerPC made on NT to date? CompuServe provides an interesting answer. Since August, users have downloaded a minuscule percentage of files for this and other RISC platforms.
Lesson: PowerPC, and RISC platforms as a whole, represent an insignificant percentage of NT desktops (Shell Technology Preview is a desktop-oriented file). They represent a greater portion of NT Servers, but they're still a minority. PowerPC has merely split the already small RISC pie among three players instead of two. The big loser in that split has been Mips Technologies, which was the first RISC architecture NT supported.
This is a pity. Many people--including me--had high hopes that NT's RISC platform support would bring some badly needed competition into the microchip market, but it didn't happen.
Something else that didn't happen in 1995 was the expected flood of 32-bit Windows applications for both Windows 95 and NT. Microsoft could point to its InfoSource CD-ROM, which lists more than 4,000 Back Office-compatible products--75 percent of which run on NT and are presumably 32 bit. But most of those are specialized--looking for word processors and spreadsheets still turns up only two products each. (I'm writing this before Fall Comdex, so there could be a surprise batch of end-of-the-year products. If that's the case, vendors are being awfully quiet.)
WINDOWS Magazine's senior technical editor Dave Methvin found out why while he was working on Wintune 95 (downloadable from our areas listed on page 18 and available on the WINDOWS CD-ROM Magazine). This test and tune-up kit is a Win32 application targeted at Windows 95 and designed to run on NT as well. Dave found Win32 development to be more difficult than he expected. The current Win32 SDKs are buggy, and the documentation is incomplete. Many incompatibilities exist between NT and Win95, and as I write this, Microsoft is still changing guidelines for Win95 developers--a good two months after Win95 shipped. I'm hoping these problems will be cleared up in 1996.
The NT 3.51 Resource Kit is finally about to ship and should be available by the time you read this. I still haven't gotten a copy. I'm expecting NT script support for both PERL (the scripting language used by World Wide Web servers) and REXX (popular with OS/2 folks), along with improved versions of several popular NT utilities, which I hope include a better DNS implementation. Multiprotocol Router might ship in the resource kit, but I doubt it. Microsoft is also offering Service Pack 2 for NT 3.51, which fixes yet more bugs. The company has released to manufacturing Back Office 1.5 (NT Server 3.51, SQL Server 6.0, MS Mail 3.5, SMS 1.1, SNA Server 2.11) and it should be available by now. Microsoft is also offering Microsoft Developers Network (MSDN) level III, something new for Back Office developers. This is basically everything from levels I and II (all SDKs and access to early Win95 and NT betas), plus a Back Office suite developmental test version. It's also a good tool for IT departments.
A correspondent who prefers to remain nameless recently pointed out something I'm not too happy about: Microsoft's Repair Disk (RDISK) utility for NT doesn't save security information--including user accounts--when you use it after you install NT. There's a difference of opinion about whether this is a bug. Deep Dark said the development group told him this behavior is by design, but TechNet yielded a product support item (PSS ID Number: Q126464) that reports it as a bug. Both groups agree on the workaround: Use NT's built-in backup (NTBACKUP) app, with the option to save/restore Registry data.
Sorry, Deep, but this time I'm with the product support folks. It's a bug. Users who create an emergency disk on setup, and then regularly update it using RDISK, ought to expect all their Registry settings would be restored, including security and user accounts. Otherwise, what good is it? With the current setup, using the emergency disk to recover after a server fails to boot will give you just one account: Administrator.
Because this information differs from what I wrote in my first NT Question and Answer file, and in my book, Networking Windows NT 3.51, I've posted corrected files (NTQA02.ZIP and NETNT02.TXT). You'll find both in the NT and Windows 95 section of our file libraries online (WINDOWS Magazine Online Locations). These files also include answers to the most common questions, as well as updated information since the book went to press.
I recently spent a day at Arbor Software's (408-727-5800, fax 408-727-7140) annual meeting for ESSbase users. This multidimensional, nonrelational database is aimed at On-Line Analytical Processing (OLAP). It's expensive--an entry-level setup runs around $43,000--but it can turn trend analysis at a big company from a task that takes weeks to one that can be completed in minutes. Users I spoke with, including representatives from ARCO, May Co. stores, the U.S. Navy, Intel and Microsoft, had nothing but good things to say about the database. The only bad comment I heard was from some IT folks who worry about end users trying to do too much, which is what IT folks usually say. Arbor originally wrote ESSbase for OS/2, but now supports it on UNIX and NT platforms.
In the bogus department ... I hate to do this, but I can't let IBM's Warp Server beta pass without comment. I haven't spent much time with it myself, but our assistant technical editor Serdar Yegulalp did, and his reaction was far from positive. In fairness, we have to tell you that he did eventually get it installed, but he described the experience as an "ugly bloody mess." IBM's "Easy Start" code name seems like a bad joke.
We're also not impressed by the feature set--Warp Server seems to be a basic bundle that includes file-and-print services from the old LAN Server product line, Warp itself, LAN Distance remote access, SystemView system management, a basic backup application and a print spooler IBM pretentiously refers to as "Advanced Print Services." Compared with NT Server, the bundle lacks Macintosh client support and isn't nearly as well integrated. We were hoping to see IBM bundle in some form of Notes server, but it's not in the beta Serdar installed. Pretty bogus, IBM!
The book of the month is A History of Knowledge by Charles Van Doren (Ballantine Books, 1992, $12.50 softbound). This isn't a computer-related book, but the final chapter contains some of the most profound thinking I've ever seen about the computer's impact on our society.
Now for the surprise. If you haven't already done so, look at the Info Files in this month's Software First Impressions. We're reporting platform compatibility for all versions of Windows, including NT. This is information many of you have requested. Some of you have also asked for more specialized high-end coverage. Later this year, you'll find a new section in WINDOWS Magazine that's aimed at the world beyond the PC desktop. I'll have a column there, in addition to my usual Windows NT column. It's going to be a great 1996 for NT.
Editor-at-Large and resident Windows NT expert John D. Ruley is the principal author of Networking Windows NT 3.51 (John Wiley & Sons, 1995). Contact John in the "Windows NT" topic of WINDOWS Magazine's areas on America Online and CompuServe. To find his E-Mail ID Click Here
Graphics Device Interface (GDI) integrated directly into the NT kernel. This is Dave Cutler's last shot at making NT run in 8MB. I don't think he'll make it, but this will improve performance, so it's worth doing anyway.
An Internet browser built directly into the SUR's shell. This will be an NT version of Microsoft's Internet Explorer browser for Win95, which is currently on beta at Microsoft's Web site (www.microsoft.com). You may still want to keep Netscape handy, but having a browser built right into the shell is convenient.
The long-awaited Windows 95-style Telephone API (TAPI) and associated modem driver. We'll finally be able to use NT as a client to the Microsoft Network. The modem driver will be either Unimodem or a hack using NT Remote Access Services to give NT equal capabilities.
A new Multiprotocol Router either built into NT Server or available as an add-on. As I write this, it's in public beta on the MSNET forum on CompuServe. It fills in one of the last places where NetWare has a feature NT lacks. Combined with RAS, it should significantly enhance NT Server's capability in WAN environments. (Editor's Note: At press time, Microsoft released a version of the Multiprotocol Router for NT Server in NT 3.51 Service Pack 2.)
NetWare file/print emulation (FPNW) and a NetWare Directory Service Manager (DSMN). The former is now shipping as an add-on for NT Server 3.51; the latter is in beta. Together, these products facilitate bringing NT Server into a NetWare environment. They enable you to use existing NetWare client software without any modification, and administer both NT Server and NetWare servers from a single graphical interface. Microsoft is also experimenting with dedicated telephone support for users converting to NT Server from NetWare (800-833-9264). The promotional price is $75 per call.
Microsoft's new DirectX low-level game API and other Win95-specific APIs for NT Workstation. Future Win95 versions will get more of the NT APIs. In the short term, this means DOOM for Windows 95 should run on NT as well. In the long run, it means a new generation of high-performance graphics in business applications like videoconferencing and presentation graphics can be developed.
Unified administration tools in NT Server. This one's chancy. It's based on an off-the-cuff comment from a Microsoft contact, but NT's administration tools are due for a face-lift. I'm hoping for something similar to the Starfighter tools introduced in SQL Server 6.0--a single, integrated management interface with OLE Automation support. That would allow an administrator to use Visual Basic for Applications (VBA) as language to write management scripts.We'll get this eventually, but maybe not in the SUR.
by: Martin Heller
IN PARADISE LOST, Milton tells the tale of a rebellion in heaven led by Lucifer, one of the brightest archangels. The revolt fails, and when the rebel and his followers are cast into the pit, he reflects:
"Here at least
We shall be free ...
Better to reign in Hell, than serve in Heav'n."
Now, you may not agree with me, but I've long thought Lucifer got a bad rap. Think about it: How much free will does an angel have? Could Lucifer have opposed God if it hadn't been God's will? Didn't Lucifer's opposition cause God to kick Adam and Eve out of that stifling Paradise and into the world where they belonged? Wouldn't it all have been too boring for words otherwise?
Although he's certainly the archetype, Lucifer isn't the only case of demonization on record. Take Microsoft--and more specifically, Bill Gates. Many imagine Bill to be Satan, reigning in hell with his 12,000-odd minions, instead of a nerdy Harvard dropout hacker with a strong sense of competition, an ability to see the obvious, and a lot of good luck and perseverance. They view Microsoft as a unified demonic hierarchy, operating with a single malicious mind, instead of a mixed collection of fairly bright, underpaid people all with different agendas, trying to operate as well as they can in a state of ever-changing goals and e-mail overload.
These same people buy Microsoft products--sometimes with justification, sometimes without. It's as though the old adage about nobody losing his or her job buying IBM has shifted to refer to Microsoft. I wouldn't lose my job talking about word processors and spreadsheets, but what I really know about are development tools. Usually, when I ask Win32 programmers which C/C++ compiler they use and which they want tools for, they say "Microsoft."
I'm not as sure. Readers, especially beginners, often send me e-mail requesting advice. After "What's the best language for a beginning programmer?" (Answer: "It depends"), the most common question is "What's the best C++ compiler?" That answer is also "It depends," although the parameters are slightly different.
I currently recommend four C/C++ compilers for Windows platforms, from Microsoft, Borland, Watcom and Symantec. One salient point is that all but Borland's come with essentially the same class library, MFC (Microsoft Foundation Class). So if you hate MFC, or love Borland's Object Windows Libraries (OWL), buy Borland. If you love MFC, buy one of the other three. Typically Microsoft's MFC version is slightly newer than Watcom's and Symantec's, but that only matters when something you need right away is added to the class library.
In addition, Microsoft offers the only compiler that's supported on RISC platforms for Windows NT. That cross-platform strategy appeals to a lot of people, and certainly convinced me for awhile. But I no longer think it's terribly important. Except in specialized areas such as engineering, software sales on Intel platforms far outweigh sales on RISC platforms like Mips, Alpha and PowerPC. Because Windows 95 is Intel-only, Intel's dominance will most likely continue. In addition, the power of the P6 processor will make it awfully hard for the others to continue to compete on performance, despite all the advantages inherent in RISC designs--small dies, low cost and so on. I'm not saying you should ignore the market for Win32 applications on RISC machines, but it isn't a life-or-death consideration.
From a performance standpoint, Watcom has consistently been my pick among compilers. There are always specific things each compiler does a little better than the others. I haven't had a chance to do a scientific comparison, but Watcom still appears to hold an edge on code optimizations. On the other hand, Watcom's previous reliance on cryptic command-line interfaces has historically produced an overall development package only a seasoned hacker could love.
That's changed in Watcom C/C++ 10.5. The company has cleaned up its development environment a bit and added Visual Programmer, an excellent visual development tool that generates MFC code. Visual Programmer is a stripped-down version of WindowsMaker Professional, licensed from Blue Sky Software. Symantec has also shipped Visual Programmer with its compiler.
Visual programming has its pros and cons. It's flexible, and it's productive if the user interface is the most important part of the application. On the other hand, visual programming can isolate you from the underlying code, and sometimes the simpler approach is just as effective. For 90 percent of the programs I've worked on, I've found generating the application's user interface with Microsoft's wizards or Borland's assistants works well and gets me to the meat of my programming in under an hour.
In its latest compiler, Visual C++ 4.0, Microsoft has made a number of productivity improvements that raise the bar for its competitors. The most important involve code reuse. The new Component Gallery is a stab at a code repository. The ability to create and use OLE controls complements the ability to create and use C++ classes. Resource templates let you reuse dialog designs and other resources. The ability to create custom AppWizards allows you to capture and distribute your own experience and standards. Finally, for those of you who like to prototype in VB, the VC++ dialog editor can now import Visual Basic forms--within limits.
Microsoft has addressed many of VC++'s shortcomings. The latest version's development environment offers the option to rebuild only files really affected by a header change. It also sports more convenient debugging, a beefed-up editor, incremental compilation and improved incremental linking. You no longer need to compile to browse your code by classes and functions. You can finally create an OLE control container as well as an OLE control. The memory allocator--the cause of the "out of virtual memory" problem first made public in this column last July--has been completely rewritten.
Many enhancements have been made to MFC. For example, the classes for OLE controls have been integrated with the rest of the framework--there's no longer a separate OLE control development kit. And the support for OLE controls and their containers is built right into the CWnd class. An OLE control in a window is treated as a special kind of child window. You can create an OLE control dynamically using CWnd: : CreateControl or statically from a dialog template, with support in the dialog editor for placing OLE controls in dialog templates just like any other kind of controls.
Along the same lines, two new classes encapsulate the OLE common dialogs for setting up printed pages and modifying the properties of OLE objects--CPageSetupDialog and COlePropertiesDialog. Similarly, new classes are provided for all the Windows 95 common controls (see A Glossary of Common Controls).
The list, tree and rich edit classes are a bit complicated to use by themselves, so the following view classes have been added: CListView, CTreeView and CRich- EditView. What's the sample program for the CRichEditView class? WordPad!
The common controls aren't the only Win32 enhancements to MFC. It finally has real support for multithreading, in the form of synchronization object classes, to supplement the existing thread-creation functions and classes. Synchronization object classes provide an interesting alternative to separate synchronization objects. You can add the synchronization objects a class needs as data members, add the synchronization code needed to the class member functions and have a thread-safe class ready to drop in place without further ado. This ease of use, however, sometimes comes at a cost to runtime speed.
MFC has finally gotten new classes for Data Access Objects (DAO)--in other words, classes to allow C++ programmers to use the same Jet database engine as Visual Basic and Access. Until now, the MFC database classes have been limited to using ODBC drivers, and until now the ODBC drivers have been slower than molasses in January.
The claim is that ODBC drivers are now much faster. I haven't had a chance to test them, but there was certainly plenty of room for improvement. The DAO classes are reputed to be faster than ODBC classes when using MDB (Access format), dBASE, FoxPro and Paradox databases; Excel and Lotus spreadsheets; and text files for data. The DAO classes--and the underlying Jet engine--can also use ODBC drivers, but this generally adds overhead and slows things down. The only advantage of using DAO is that the Jet engine can perform heterogeneous joins, which can be a big help when you're trying to build a table from multiple data sources.
Building a DAO application with VC++ works much like building an ODBC. You start with AppWizard, select DAO database support and pick a database. AppWizard knows only about MDB files, so if you want to use another kind of database at this point you need to attach it to an Access database. You have the option of selecting a snapshot, dynaset or table for your recordset. You also have the options to detect dirty columns and bind all columns.
Once you've generated your code you can use the dialog editor to design a data-entry form, and ClassWizard to bind controls on the form to fields in your recordset. You can use list boxes, combo boxes or grid controls to add browses, and you can populate them from appropriately filtered and sorted recordsets.
It'll take me awhile to absorb this, but at first examination I'd say that DAO turns VC++ into a fairly serious database development tool right out of the box, with no need for third-party libraries or drivers. I doubt Oracle is worried, but some of the less-secure database tool vendors might well consider, to paraphrase Milton, wheth'r th' Almighty, who hath now built here for his envy, might yet drive us hence.
Senior Contributing Editor Martin Heller lives between heaven and hell in a place called Andover, Mass., with his wife, one remaining cat and four children. In his spare time, Martin likes to program computers. Contact Martin in the "Programming Windows" topic of WINDOWS Magazine's areas on CompuServe.To find his E-Mail ID Click Here
CAnimateCtrl: This class displays successive frames of an Audio Video Interleaved (AVI) clip during a lengthy operation.
CHeaderCtrl: This resizable button appears above a column of text, allowing you to display more or less information in the column.
CHotKeyCtrl: Create a hotkey with this window.
CImageList: Manage sets of icons or bitmaps.
CListCtrl: Display a collection of items, each consisting of an icon and a label.
CProgressCtrl:This is a progress bar.
CRichEditCtrl: Include embedded OLE objects, and enter and edit text with character and paragraph formatting within this window.
CSliderCtrl: This is a trackbar.
CSpinButtonCtrl: Control up-down movement.
CStatusBarCtrl: This status bar resembles the MFC CStatusBar class.
CTabCtrl: MFC class CPropertySheet is similar to this tab control.
CToolBarCtrl: This button bar resembles the MFC CToolBar class.
CToolTipCtrl: Implement a small pop-up text window that describes the purpose of a toolbar button or other application tool.
CToolBar: This class implements its own tool tips.
CTreeCtrl: The Windows 95 Explorer uses this tree view.
CDaoWorkspace: This class defines an open session, contains databases and provides a mechanism for multidatabase transactions.
CDaoDatabase: Here, a single database connection is represented.
CDaoTableDef This represents the schema of a database. Unlike the ODBC classes, the MFC DAO classes let you manipulate your database schema. You can create and delete fields and even create and delete indexes.
CDaoRecordset: Select one or more columns from rows of one or more database tables, as well as the field values for the current record. A recordset is often the result of a query, represented by a CDaoQueryDef.
CDaoException: Handle unexpected conditions in the database